1. Field of the Invention
The present invention relates to process automation and, more specifically, to a method and system for automating actions taken with respect to a man-machine-interface (MMI) between computers or other computerized devices and a user.
2. Description of the Related Art
Most systems, whether they are hardware systems or software systems, have MMIs for interfacing with a user. For example, the MMI is used by the user to generate commands to be run by the hardware or software system and receive and display the responses generated in response to those commands. One simple example of an MMI in a software system may be an Internet web page that requires a user to enter a login ID and a password to log into the web page. When the Internet web page is to be tested, it may be necessary to enter various combinations of login IDs and passwords into the Internet web page to confirm the login feature of the web page. Another example of an MMI for hardware systems may be the command line interface (CLI) of a network switch or a router. A user may issue various commands to such router via its CLI to test various functionalities of the router. Most hardware or software systems require quality assurance (QA) and system verification tests (SVT) before it is released for actual use by the public. It is preferable to automate SVT process, so that the SVT process can be carried out efficiently and accurately.
Software test automation, or process automation in general, typically requires that a testing program operate like a human interacting with a command-line interface (CLI) via protocols such as telnet, SSH (Secure Shell), or via a serial port. FIG. 1 illustrates a conventional SVT system interacting with a system under test (SUT). The SUT 120 may be, for example, a router or network switch to be tested, and the testing system 100 may be a computer used by a user to test the SUT 120. The testing system 100 includes a MMI 180 such as a CLI or a graphical user interface (GUI) such as a web page or a Java application. The testing system 100 (such as a test program) sends requests 140 containing commands to the SUT 120 to perform a configuration step in the test or to extract information from the SUT 120. The user of the testing system 100 uses the MMI 180 to issue such requests 140. In response to the requests 140, the SUT 120 sends responses 160 to testing system 100. The responses 160 may be text, or otherwise formatted in a way intended for human operators or users 191 to digest.
Such testing process may be automated by use of “scripts” 190 that contain a collection of such requests 140 to be issued to the SUT 120. The script 190 describes a procedure to be followed by the testing system 100 to automate a task that would otherwise be performed by a human user 191. This script 190 can be written in a variety of different languages that a computer testing system 100 can interpret to drive the MMI 180 and issue the requests 140 to the SUT 120 and receive responses 160 based on the issued requests 140. The script 190 performs tasks through these MMIs 180 in the same way a human user 191 might do it, for example, by sending commands to a CLI, clicking buttons on a GUI, entering arguments for certain commands, etc.
While using scripts 190 has the advantage of automating the process of running tests on the SUT 120, the creation of these scripts 190 is complex and time-consuming. Conventional techniques for generating scripts for test automation or other process automation include a capture-generate method and a keyword-driven method.
In the capture-generate method, the testing system computer 100 monitors and captures all the requests (actions) 140 made as the human user 191 performs the task once and uses this information to generate a script that will perform the same actions 140 in the same sequence based on the captured requests. The capture-generate method is very fast, simple, and easy to use, but has many shortcomings. Most notable among these shortcomings is that the script generated by the capture-generate method tends to be verbose and difficult to maintain, because it will consist of a long sequence of low-level actions corresponding to all the recorded low-level actions 140 taken by the user. For example, when working with a GUI 180, the human user 191 may fill in a form on a screen displayed on the MMI 180 of the testing system computer 100, which may be captured as a long sequence of mouse clicks, keyboard actions, or perhaps, at best, control-specific actions. The capture-generate technique fails to capture the overall structure of the recorded test procedure and therefore produces scripts that are not modular or reusable.
On the other hand, the keyword-driven method uses a higher-level computer language where a list of “keywords” are assembled by the human user 191 to describe the overall flow of the test/process, where each keyword corresponds to a script or script fragment that will perform the actual actions (requests) 140 to accomplish the sub-tasks. The keyword-driven approach simplifies the task of automation, especially for human users that are not computer programming experts. If a full set of keywords can be implemented, then it can be useful in automating the test or other process automation. However, the keyword-driven method is less intuitive for users compared with the capture-generate method and is not as fast for most situations. Also, the keyword-driven method requires that a comprehensive set of keywords be implemented a priori, in advance of any actual test run on the SUT 120.